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AUTOCREW  IMPLEMENTATION: 


INBOUND  SURFACE-TO-AIR  MISSILE  SIMULATION 

1.  Introduction 

Nine  multiple  cooperating  rule-based  systems  for  the  combat  aircraft  environment 
were  developed  and  implemented  in  the  AUTOCREW  expert  system  [1].  Each  component 
rule-based  system  is  modelled  on  a  typical  World  War  II  bomber  crew  member  having  specific 
task  responsibilities.  The  bases  for  modelling  integrated  rule-based  systems  as  crew  members 
are  twofold.  First,  tasks  performed  by  crew  members  arc  easily  identified,  well-defined,  and 
familiar  to  operations  personnel  and  aircraft  system  designers.  The  issue  of  task  familiarity  is 
essential  from  a  human  engineering  standpoint.  For  example,  the  pilot  of  a  single-seat  combat 
aircraft  categorizes  the  tasks  he  performs  into  logical  groups  such  as  navigation,  flight  control, 
systems  monitoring,  failure  diagnosis,  and  fire  control  operations.  Implementing  an  Al-based 
pilot  aid  as  a  logical  extension  of  human  operations  is  highly  desirable.  The  pilot  must  idetify 
with  the  task  performed  by  the  on-board  aid,  so  a  crew-model  design  of  component  knowledge 
bases  is  commensurate  with  the  pilot’s  experience  and  training. 

The  AUTOCREW  crew  members  are  responsible  for  performing  tasks  and 
controlling  functions  associated  with  the  aircraft  and  on-board  systt  js.~1fhe  modelled  crew 
members  are  COPILOT  (flight  control),  ENGINEER  (system  diagnosis,  reconfiguration), 
NAVIGATOR  (navigation),  COMMUNICATOR  (radio/data  operations),  OBSERVER 
(lookout  and  alarm)  ATTACKER  (offensive  weapon  control),  DEFENDER  (defensive  weapon 
control),  and  SPOOFER  (countermeasures).  The  ninth  rule-based  system  (EXECUTIVE), 
functions  on  a  higher  level  than  the  preceding,  more  task- specific  systems.  The  EXECUTIVE 
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coordinates  mission-specific  tasks  and  has  knowledge  of  the  mission  plan.  The  human  Pilot 
acts  in  the  capacity  of  mission  coordinator.  He  monitors  the  AUTOCREW  systems  and  attends 
to  mission  planning  and  problems  brought  to  his  attention  by  the  AUTOCREW  components. 

Kp.y  Surv-J.i+W  Jl'iS  1.  ■-  ( \r C  .  -|  “5',;. 

'  ,  2.  Development  of  Rule-Based  System  Cooperation 

The  AUTOCREW  knowledge  bases  arc  developed  and  implemented  independently. 
Shared  parameters  are  identified  throught  the  design  process.  These  "global"  variables  are 
used  to  exchange  information  between  knowledge  bases.  A  change  in  value  of  a  shared 
parameter  in  one  knowledge  base  can  invoke  search  activity  within  another  knowledge  base. 
Hence,  dynamic  changes  in  the  aircraft  environment  are  reflected  and  handled  appropriately 
within  each  AUTOCREW  knowledge  base. 


3.  Knowledge-Base  Development  and  Implementation 
3.1  Knowledge-Base  Development 

Before  implementing  a  knowledge  base  in  the  development  environment,  a  graphical 
representation  of  the  structure  is  formed,  thereby  providing  a  first  glance  overview  of  the 
knowledge  base.  This  greatly  facilitates  modification  of  the  knowledge  base  structure  and 
content.  A  graphical  representation  of  the  DEFENDER'S  knowledge  base  is  shown  in  Fig.  1. 
Rectangular  boxes  represent  knowledge-base  parameters  and  ovals  represent  rules.  Parameters 
describe  factual  information  about  the  domain,  whereas  rules  describe  the  procedural 
relationships  between  parameters.  The  "state"  of  a  parameter  is  denoted  by  its  value. 


Parameter  values  reside  in  slots  within  a  parameter  box.  Lines  connecting  parameters  via  rules 
form  the  procedural  relationships  between  parameters.  An  AND  relationship,  denoted  by  a 
joining  arc  between  parameters  is  shown  n  Rule  D005.  An  example  of  an  OR  relationship  is 
shown  in  Rule  D001 ;  this  rule  is  read 

IF 

the  value  of  the  parameter 

INBOUND  ENEMY  is  NONE 

OR 

the  value  of  the  parameter 

DEFENDER  SUCCESS  has  been  determined 

THEN 

set  the  value  of  the  parameter 

DEFENDER  SEARCH  COMPLETED  to  TRUE 

The  basis  for  cooperative  activity  among  rule-based  systems  is  the  concept  of 
shared  parameters.  The  symbol  "S"  denotes  shared  parameters  in  the  DEFENDER'S 
knowledge  base  shown  in  Fig.l.  The  parameters  INBOUND  ENEMY  and  INBOUND 
DIRECTION  are  shared  parameters,  residing  in  the  DEFENDER  and  OBSERVER  knowledge 
bases.  The  OBSERVER  supplies  these  parameters  through  assessment  of  the  external 
environment.  The  DEFENDER  uses  the  parameters  to  decide  when  activation  of  the  defensive 
fire  control  system  is  warranted.  The  remaining  seven  knowledge  bases  also  use  these 
parameters  to  decide  when  additional  tasks  need  to  be  performed. 

In  order  to  simulate  a  realistic,  dynamic  environment  in  which  the  rule-based 
systems  operate,  the  values  of  several  parameters  may  be  changed  at  any  time  during  the 
simulation.  These  parameters  are  denoted  by  the  symbol  "D"  in  Fig.  1.  The  designer  testing 
the  knowledge  base  changes  the  parameter  values  to  test  the  search  logic  flow.  In  an 


operational  system,  the  values  of  these  parameters  would  be  determined  from  sensor 
measurements. 

The  provision  for  user  interaction  with  a  dynamic  rule-based  system  is  necessary 
in  order  to  allocate  full  control  of  the  software  framework  to  the  user.  Parameters  that  must 
have  their  values  supplied  by  the  user  are  denoted  in  Fig.l  by  shaded  areas  surrounding  the 
lower  portions  of  parameter  boxes.  For  example.  Rule  D007  is  interpreted  as 

"determine  the  value  of  the  parameter  PILOT 
SELECTS  WEAPON  by  asking  die  user  to  provide 
its  value.  When  a  value  has  been  assigned,  set  the 
parameter  DEFENDER  WEAPON  SELECTED  to 
TRUE." 

Rule  D007  also  demonstrates  how  the  search  process  is  controlled  utilizing  "don’t  care" 
or  "fuzzy"  parameter  states.  The  premise  of  Rule  D007  is  satisfied  when  any  value  of  the 
parameter  PILOT  SELECTS  WEAPON  is  determined. 

3.2  Knowledge-Base  Implementation 

The  Princeton  Rule-Based  Controller  (PRBC)  is  a  unique  software 
architecture  for  combining  procedural  and  symbolic  processing  for  rule-based  system 
development  [2].  The  knowledge  base  is  developed  in  the  IQLISP  computer  language 
and  is  translated  with  the  inference  engine  into  the  Turbo  PASCAL  computer  language. 

The  PRBC  is  a  highly  flexible  development  tool;  numerical  code  is  developed  in  the 
naturally  procedural  language  PASCAL,  and  the  knowledge  base  is  developed  in  the 
naturally  symbolic  language  LISP.  The  ease  with  which  PASCAL  code  can  be  embedded 
in  the  knowledge  base  structure  makes  the  PRBC  a  highly  suitable  tool  for  task  and 
algorithm  scheduling. 

Listing  1  shows  how  the  graphical  representation  of  the  DEFENDER 
knowledge  base  in  Fig.  1  is  implemented  using  PRBC  syntax.  Each  rule  contains 
PREMISE  (if)  and  ACTION  (then)  statements  that  describe  the  parameter  rule  relations 
depicted  in  the  graphical  representation.  What  is  not  shown  in  the  knowledge  base  of  Fig. 

1  is  embedded  PASCAL  code  contained  in  the  PREMISE  and  ACTION  statements  of  the 
rules.  For  example,  Rule  D006  in  Listing  1  illustrates  how  calls  to  the  PASCAL  routines 
"trckng_scnng_enmy;",  "fire_cntrl_lckd_on;"  and  "enmy_tijctry_computed;"  are  defined 
within  the  rule's  action.  The  PASCAL  procedures  are  ignored  during  knowledge  base 
testing  in  LISP.  When  the  knowledge  base  is  translated,  calls  to  the  PASCAL 
procedures  are  scheduled  using  search.  The  search  logic  can  be  tested  in  both  the  LISP 
and  PASCAL  development  environments.  The  PRBC  Development  System  inference 


engine  uses  goal-directed,  depth-first  search  to  operate  on  a  knowledge  base. 


4.  Simulation  Testbed  And  Results 


AUTOCREW  Simulator 


The  simulation  testbed  for  AUTOCREW  resides  on  an  IBM  PC-AT  computer. 
In  order  to  simulate  the  dynamic  flight  environment  realistically,  an  interactive  testbed 
was  devised  using  the  computer  keyboard  as  the  simulation  controller.  Coded  keystrokes 
control  the  values  of  several  knowledge-base  parameters,  thereby  allowing  the  designer 
to  test  search  activity  interactively  by  changing  parameter  values.  Hence,  the  designer 
can  control  and  verify  the  knowledge-base  logic  flow  and  change  the  simulation  on-line. 
This  method  is  most  representative  of  the  actual  dynamic  flight  environment.  When  all 
simulation  possibilities  have  been  tried,  the  designer  can  make  suitable  adjustments  to  the 
knowledge  base  and  continue. 

Interaction  with  AUTOCREW  is  via  the  keyboard  and  graphics  display.  The 
AUTOCREW  display  as  shown  during  an  inbound  SAM  simulation  is  depicted  in  Figure 
2.  Shown  are  nine  window  areas  for  each  AUTOCREW  member.  Messages  are  sent  to 
the  Pilot  from  AUTOCREW  and  displayed  in  the  appropriate  window  area.  The  most 
useful  messages  during  preliminary  design  of  multiple  cooperating  expert  systems  are 
those  that  tell  the  designer  which  tasks  would  be  performed  in  the  fully  developed 
system.  When  an  AUTOCREW  member  requires  attention,  the  window  area  assigned  to 
the  AUTOCREW  member  flashes.  Another  feature  of  the  Pilot/AUTOCREW  graphics 
interface  are  controlled  scrolling  of  old  information.  Although  an  operational 
AUTOCREW  would  surely  use  graphical  representation  of  AUTOCREW  activities  and 
data,  the  developed  testbed  gives  the  designer  a  good  idea  of  crew  member  cooperation 
and  Pilot/AUTOCREW  interaction  in  the  early  development  stages. 


4.2  Inbound  Surface-to-Air  Missile  Example 


A  description  of  the  AUTOCREW  simulation  shown  in  Fig.  2  demonstrates 
system  cooperation.  Initially,  the  OBSERVER  reports  "all  clear"  as  external  sensors  have 
not  detected  anything.  The  message  is  repeated  upon  each  sensor  sweep  until  a  simulated 
SAM  detection  occurs.  Then,  the  OBSERVER'S  parameter  INBOUND  ENEMY 
changes  from  NONE  to  SAMS.  In  the  simulation,  the  inbound  direction  displayed  with 
the  "SAMS!!"  message  is  a  randomized  integer  value  of  the  OBSERVER’S  parameter 
INBOUND  DIRECTION.  The  SAMS  value  of  INBOUND  ENEMY  triggers  search 
activity  within  the  DEFENDER  knowledge  base.  The  DEFENDER  asks  the  Pilot  to  arm 
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the  defensive  fire  control  sequence.  The  DEFENDER  then  engages  the  tracking  radar, 
the  fire  control  system  locks  onto  the  SAM  and  computes  the  expected  SAM  trajectory. 
The  COMMUNICATOR  reports  the  SAM  attack  to  the  Pilot’s  wingmates  and  the  control 
base.  The  DEFENDER  calculates  the  circular  error  probables  (CEP)  of  the  on-board 
defensive  weapons  to  find  the  best  one  for  SAM  destruction.  In  addition,  the 
DEFENDER  attempts  to  classify  the  SAM  using  signal  information  obtained  from  the 
OBSERVER  and  its  own  sensors.  Knowledge  of  the  SAM  classification  and  defensive 
weapon  CEPs  aids  in  the  DEFENDER'S  selection  of  the  best  and  next-best  weapons. 
Once  found,  the  Pilot  is  asked  to  confirm  the  recommended  weapon  (MISSILE  #1).  If 
the  Pilot  inputs  NO,  then  the  next-best  weapon  is  presented.  In  the  event  that  the  Pilot 
has  armed  the  system  and  not  disagreed  with  the  selection  within  a  given  time,  the 
DEFENDER  selects  the  weapon  and  proceeds  with  the  fire  control  sequence. 

While  the  DEFENDER  performs  these  tasks,  the  COPILOT  defines  and 
performs  an  evasive  maneuver,  subject  to  the  Pilot's  approval.  The  SPOOFER  selects 
and  deploys  countermeasures  appropriate  to  a  SAM,  and  the  OBSERVER  attempts  to 
determine  the  SAM  launch  site.  The  COMMUNICATOR  displays  SAM  confirmation 
messages  from  the  Pilot’s  wingmates.  The  ENGINEER  continues  to  monitor  the  aircraft 
systems  and  evaluates  the  aircraft's  capabilities  for  the  COPILOT.  The  NAVIGATOR 
locates  the  nearest  friendly  air  bases  and  searches  for  friendly  aircraft  to  provide  possible 
fire  support  against  the  SAM  site.  Since  U:c  aircraft  is  proceeding  to  the  target  area  as 
planned,  the  ATTACKER  continues  preparing  for  mission  target  engagement.  The 
EXECUTIVE'S  responsibilities  are  to  analyze  the  current  mission  status  and  prioritize 
and  coordinate  AUTOCREW  tasks.  The  EXECUTIVE  orders  additional  AUTOCREW 
tasks  to  assist  in  mission  status  assessment  and  in  achieving  mission  goals. 

The  messages  in  the  DEFENDER’S  display  area  "trckng_scnng_enmy;", 
"fire_cntrl_lckd_on;",  "enmy_trjctry_cmpt;”  and  ’’computing_cep;"  are  PASCAL 
procedures  that  would  control  and  perform  their  implied  tasks.  The  PASCAL  routines 
that  perform  these  tasks  remain  to  be  developed.  Hence,  the  cooperating  rule-based 
system  designer  gets  a  realistic  overview  of  AUTOCREW  functions  before  developing 
the  details. 

5.  CONCLUSIONS 

Nine  cooperating  rule-based  systems  for  aircraft  control  were  implemented 
using  the  Princeton  Rule-Based  Controller  (PRBC)  Development  System  on 
single-processor  IBM  PC-AT  computer.  Each  component  knowledge  base  of 


AUTOCREW  was  modelled  as  a  typical  World  War  II  bomber  crew  member  performing 
routine  and  specialized  tasks.  The  AUTOCREW  organizational  approach  facilitates  the 
breakdown  and  distribution  of  flight  tasks  in  a  consistent  and  natural  manner,  amenable 
to  the  designer's  experience.  Logical  task  distribution  aids  in  knowledge-base 
development  and  in  identifying  cooperative  tasks  in  a  multiple  rule-based  system. 

Many  advantages  can  be  drawn  from  global  implementation  within  a 
multiple-system  framework.  Using  the  PRBC  development  tool  and  an  interactive 
simulation  testbed,  it  was  demonstrated  that  an  effective  simulation  of  pilot-system 
interaction  and  intersystem  cooperation  could  be  obtained.  It  also  was  shown  that 
minimal  knowledge-base  details  were  needed  to  implement  realistic  simulations.  These 
simulations  enable  the  designer  to  identify  areas  of  extensive  system  cooperation  and  to 
plan  future  individual  knowledge-base  requirements  more  efficiently. 
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Listing  1.  Skeletal  DEFENDER  Knowledge  Base 


(RULE  OOOl 
(PREMISE ' 

($OR 

($60  INBOUND_ENEMY  NONE) 
($DETERMINE_VALUE_OF  DEFENDER_SUCCESS))] 

(ACTION  '($SETQ  DEFENDER_SEARCH_COMPLETED  TRUE)!) 


(RULE_D002 

[PREMISE  '(SEQ  ATTACK_OR_ABORT  'ABORT)) 

(ACTION  '($SETQ  DEFENDER_SUCCESS  FALSE)]] 
[RULE_D003 

(PREMISE  '($EQ  ATTACK_OR_ABORT  'ATTACK)] 

[ACTION  '((SPASCAL  ’cntng_dwn_r!  sng_wpn ;*) 

($SETQ  DEFENDER_COUNTDOWN_RELEASE  TRUE) 
($SETQ  DEFENDER_SUCCESS  TRUE))]) 

[RULE_0004 

[PREMISE  '($EQ  PI LOT_CON FIRM ED_E N EMY  'NO)] 

[ACTION  '($SETQ  ATTACK_OR_ABORT  ’ABORT)]] 


[RULE_D005 
(PREMISE ' 

(SAND 

($EQ  PILOT_CONFIRMED_ENEMY  -YES) 

($EO  TRAJECTORY_COMPUTED  TRUE) 
($EODEFENDER_WEAPON_SELECTED  TRUE) 

($EO  RELEASE_POINT_COMPUTED  TRUE))] 

[ACTION  '((SPASCAL  "askjor  _pe'am*ter('anack/abort', 
anacK_or_abort,  defender) ;") 

(SSETO  ATTACK_OR_ABORT  A  TTAC  K_OR_ABORT ) )]] 
[RULE_D00€ 

(PREMISE  '(SNOT  ($EQ  INBOUND_DIRECTION  t»)] 

[ACTION  '((SPASCAL  *trckng_*cnng_enmy; 
tire_cnirlJckd_on; 
enmy_trjctry_oompoied,*) 

(SSETQ  DEFENDER_TRACK_SCAN  TRUE) 

(SSETO  FIRE_CONTROL__STATUS  ’LOCKED_ON) 

(SSETQ  TRAJECTORY_COMPUTED  TRUE))]) 

|RULE_D007 

(PREMISE  '((SPASCAL  *compoting_cep;') 

(SOR 

(SEQ  PILOT_CONFIRMS_WEAPON  "YES) 
(SDETERMINE_VALUE_OFPILOT_SELECTS_WEAPON)))] 

(ACTION  XSSETQ  DEFENDER_WEAPON_SELECTED  TRUE)]] 

P'lLE  0008 

[PREMISE  (SEQ  RULE_TESTED  TRUE)] 

(ACTION  '((SPASCAL  'CTnptr>g_rl«ase_pnI;') 

(SSETO  RELEASE_POINT_COMPUTED  TRUE))]] 


DEFENDER 

confrm  enemy:  YES 
trckng_scnng_enmy; 
fire_cntrl_lckd_on; 
enmy_trjctry_cmpt; 

ATTACKER 

cnlnuing_atk_prep; 

SPOOFER 

deploying_ECM; 

NAVIGATOR 

fndng_clsest_base; 

fndng_frndly_AC; 

EXECUTIVE 

anlyzng_situtn; 
chckng_mssion_pla  n ; 
adtnal_tsks_ordrd; 

COPILOT 

fndng_evsve_mnvr; 

OBSERVER 

all  clear; 

all  clear; 
all  clear; 

SAMS!!  at  1  o'clock 
fndng_SAM_lnchpt; 

ENGII^ER 

mntrng_systms; 

cmptng_AC_capablts; 

communicatSS 

messages_out;  B 

AC#3  undr  SAM  atk  H 
messagesjn;  || 

wngmt  #1  cnfrm  •nmyjp 

confrm  weapon  MISSILE  #1  (YES  NO)  :  yes 


Figure  2.  Display  of  Inbound  SAM  Simulation 
At  Detection  Time 


7.  AUTOCREW  Knowledge  Case  Listings  For  Inbound  SAM  Attack  Simulation 


The  nine  AUTOCREW  member  knowledge  bases  are  found  in  the  following 

sections: 

7.1  ATTACKER  Knowledge  Base 

7.2  DEFENDER  Knowledge  Base 

7.3  SPOOFER  Knowledge  Base 

7.4  NAVIGATOR  Knowledge  Base 

7.5  EXECUTIVE  Knowledge  Base 

7.6  COPILOT  Knowledge  Base 

7.7  OBSERVER  Knowledge  Base 

7.8  ENGINEER  Knowledge  Base 

7.9  COMMUNICATOR  Knowledge  Base 

The  DEFENDER'S  knowledge  base  has  been  slightly  modified  from  the  one  discussed 
in  section  5.  Some  rules  have  been  added  and  some  have  been  reordered.  These 
changes  do  not  in  any  way  change  the  simulation  described  in  section  5. 

Each  knowledge  base  has  been  trimmed  from  a  larger  parent  knowledge  base 
so  that  only  the  decision  branch  relevant  to  the  inbound  SAM  simulation  remains.  This 
facilitates  a  clear  overview  of  the  knowledge-base  functions  and  implementation 
methodology.  A  graphical  representation  of  each  knowledge  base  precedes  each 
implemented  code  structure. 


Figure  7.1  Attacker  Knowledge  Base 


Listing  7.1  Attacker  Knowledge  Base 


attacker  kb  for  SAM  attack  demo 

assumes  fighter  is  closing  in  on  target  when  SAM  is  released 


(SETQ  *SYSTEM_ID_CHARACTER*  "A4") 
(SETQ  *EXPERT_ID*  "attacker") 

attacker  parameters 


[  INTERN_SYMBOL_GROUP  *ATTACKER_PARAMETERS* 

[ATTACKER_SEARCH_COMPLETED 

(EXPECT  ’BOOLEAN)] 

[ CLOSING_ON_TARGET 

(EXPECT  ’BOOLEAN) 

( INITIAL_VALUE  ’TRUE)] 


attacker  rules 

(  INTERN_SYMBOL_GROUP  *ATTACKER_RULES* 

[ RULE_A0 1 

(PREMISE  ' ($EQ  CLOSING_ON_TARGET  ’TRUE)] 

(ACTION  '(  ($ PASCAL  "cntnuing_atk_prep; " ) 

( $SETQ  ATTACKER_SEARCH_COMPLETED  ’TRUE))] 

]  ] 

(FIND  PARAMETER  RULE  RELATIONS  * ATTACKER  PARAMETERS*  * ATTACKER  RULES*) 
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Listing  7.2  Defender  Knowledge  Base 


defender  kb  for  SAM  attack  simulation 

assumes  that  SAM  defense  is  successful  (i.e  SAM  destroyed) 

shared  parameters  (with  executive)  are  LAUNCH__CLEARANCE 

SUCCESS_DETERMINED 
(with  observer)  INBOUND_ENEMY 

INBOUND_DIRECTION 

also  top  level  parameters  of  all  eight  remaining  knowledge  bases 


(SETQ  *SYSTEM_ID_CHARACTER*  "D4") 
(SETQ  *EXPERT_ID*  "defender") 


defender  parameters 


t INTERN_SYMBOL_GROUP  *DEFENDER_PARAMETERS  * 


[ DEFENDER_SEARCH_COMPLETED 


[DEFEND_SUCCESS 


[DEFEND_COUNTDOWN_RELEASE 


[ ATTACK_OR_ABORT 


[TRAJECTORY  COMPUTED 


[ DEFEND_WEAPON_SELECTED 


[ WEAPON_RECOMMENDED 


(EXPECT  'BOOLEAN)] 


(EXPECT  'BOOLEAN)] 


(EXPECT  ’BOOLEAN)] 


(EXPECT  '(ATTACK  ABORT))] 


(EXPECT  'BOOLEAN)] 


(EXPECT  'BOOLEAN)] 


(EXPECT  '(NONE  MSSL_1  MSSL_2  MSSL_3  MM20_GUNS) )] 


[ DEFEND_RELEASE_PO I NT_COMPUTED 

( EXPECT  ' BOOLEAN ) ] 


[ P ILOT_CONFIRMED_ENEMY 


[ DEFEND_FI RE_CONTROL_S TATUS 


[ DEFEND_TRACK_SCAN 


[ P ILOT_CONFIRMS_WEAPON 


(EXPECT  '(YES  NO))] 


( EXPECT  ' ( LOCKED_ON  NOT_READY ) ) ] 


(EXPECT  'BOOLEAN)] 
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'X'A’.Va’Va-a 


■  y  v 


(EXPECT  '(YES  NO)  )] 


t  P ILOT_SELECTS_WEAPON 


[ RULE__TESTED 


(EXPECT  ’(NONE  MSSL_1  MSSL_2  MSSL_3  MM20_GUNS) ) ] 


(EXPECT  ’BOOLEAN) 

( INITIAL_VALUE  ’TRUE)] 


defender  rules 


[ INTERN_SYMBOL_GROUP  *DEFENDER_RULES * 


[RULE_D01 

[PREMISE  '  ( $OR  ($EQ  INBOUND__ENEMY  ’NONE) 

( $DETERMINE_VALUE_OF  DEFEND_SUCCESS ) ) ] 

[ACTION  ’ ( 

($SETQ  DEFENDER_SEARCH_COMPLETED  ’TRUE) 

( $ PASCAL 

"  initialize_buf fers  ( defender ) 
of f_screer ' defender ) ; 
start_up_display ,• " ) 

)]  ] 


[RULE_D02 

[PREMISE  ' ($EQ  ATTACK_OR_ABORT  ’ATTACK)] 
[ACTION  ' ( 

($SETQ  DEFEND_COUNTDOWN_RELEASE  ’TRUE) 

( $ PAS CAL 

”cntng_dvm_rlsng_wpn ; ” ) 

( $SETQ  DEFEND_SUCCESS  ’TRUE) 

( $UNSETQ  SUCCESS_DETERMINED) 

( $DETERMINE_VALUE_OF  SUCCESS_DETERMINED ) 
($SETQ  I NBOUND_ENEMY  ’NONE) 

)]  3 


[RULEJD03 

[PREMISE  ’ ( $OR  ($EQ  I NBOUND_ENEMY  ’NONE) 

($EQ  ATTACK_OR_ABORT  ’ABORT))  ] 

[ACTION  '(  ( $SETQ  DEFEND_COUNTDOWN_RELEASE  ’FALSE) 
($SETQ  DEFEND_SUCCESS  ’FALSE))]  ] 


[RULE_D04 

[PREMISE  ' ( $AND  ($EQ  PILOT_CONFIRMED_ENEMY  ’YES) 
($EQ  TRAJECTORY_COMPUTED  ’TRUE) 
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($EQ  DEFEND_WEAPON_SELECTED  'TRUE) 

($EQ  DEFEND_RELEASE_POINT_COMPUTED  'TRUE)  )] 

[ACTION  ' ( 

($  PAS  CAL 

" ask_f or_parameter ( ’ ’ attack/abort  ' ’ , attack_or_abort , defender ) ; " ) 
($SETQ  ATTACK_OR_ABORT 

( $  PASCAL  "  p [ ATTACK_OR_ABORT] . s_value" ) ) )  ]  ] 


[RULE_D05 

[PREMISE  ' ($EQ  PILOT_CONFIRMED_ENEMY  'NO)] 
[ACTION  ' ($SETQ  ATTACK_OR_ABORT  ’ABORT)]  ] 


[RULE_D06 

[PREMISE  ' ( $EQ  RULE_TESTED  ’TRUE)] 

[ACTION  ' ( 

( $ DETERMI NE__VALUE_OF  ENG INEER_SEARCH_COMPLETED ) 

( $ DETERMI NE_VALUE_OF  SPOOFER_SEARCH_COMPLETED ) 

( $ DET£RMINE_VALUE_OF  NAVIGATOR_SEARCH_COMPLETED ) 

( $DETERMINE_VALUE_OF  COMMUNICATOR_SEARCH_COMPLETED ) 

( $ DETERMI NE_VALUE_OF  OBSERVER_SEARCH_COMPLETED ) 

( $DETERMINE_VALUE_OF  COPILOT_SEARCH_COMPLETED ) 

( $ DETERMI NE_VALUE_OF  ATTACKER_S EARCH_C OMPLETED ) 

( $ DETERMI NE_VALUE_OF  EXECUTIVE_SEARCH_COMPLETED ) 

( $PASCAL 

"ask_for_parameter(  '  'cnfrm  enemy  '  '  ,pilot_confirmed_enemy, 
defender);") 

( $SETQ  P ILOT_CONF I RMED_ENEMY 
($ PASCAL 

"p [PILOT_CONFIRMED_ENEMY] . s_value" ) ) 

)]  ] 


[RULE_D07 

[PREMISE  ' ($NOT  ($EQ  INBOUND_DIRECTION  ’0))  ] 

[ACTION  ' ( 

($ PASCAL 

"trckng_scnng_enmy ; " ) 

($SETQ  DEFEND_TRACK_SCAN  'TRUE) 

($ PASCAL 

" f ire_cntrl_lckd_on ; " ) 

( $SETQ  DEFEND_FIRE_CONTROL_STATUS  ' LOCKED_ON ) 
($ PASCAL 

" enmy_tr j  ctry_computed ; 
calculating_cep; " ) 

($SETQ  TRAJECT ORY_COMPUTED  ’TRUE) 

( $ DETERMI NE_VALUE_OF  LAUNCH_CLEARANCE )  )]  ] 


[RULE_D08 

[PREMISE  ' ($EQ  RULE_TESTED  'TRUE)] 
[ACTION  ' ( 
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( $SETQ  WEAPON_RECOMMENDED 

($ PASCAL  "p [ WEAP ON_RECOMMENDED ] . s_value" ) ) 

($ PASCAL 

"ask_for_parameter( ’ 'cnfrm  weapon  ' '  + 

symbol_name[p[WEAPON_RECOMMENDED] .s_value] , 
pilot_confirms_weapon, defender) /" ) 

($SETQ  PILOT_CONFIRMS_WEAPON 
($ PASCAL 

"p [PILOT_CONFIRMS_WEAPON] . s_value" ) ) 

)]  1 


[RULE_D09 

[PREMISE  ' ( $0R  ($EQ  PILOT_CONFIRMS_WEAPON  'YES) 

( $DETERMINE_VALUE_OF  PILOT_SELECTS_WEAPON) )  ] 

[ACTION  ' ($SETQ  DEFEND_WEAPON_SELECTED  'TRUE)]  ] 


[RULE_D10 

[PREMISE  ' ( $EQ  RULEJTESTED  'TRUE)] 

[ACTION  ' ( 

($ PASCAL 

"ask_for_parameter( ' 'your  choice' ' ,pilot_selects_weapon, defender) ; " ) 
($SETQ  PILOT_SELECTS_WEAPON 
($ PASCAL 

"p [PILOT  SELECTS JWEAPON] . s_value" ) ) 

)]  J 


[RULE_D11 

[PREMISE  ' ( $EQ  RULEJTESTED  ’TRUE)] 

[ACTION  ’ ( 

($ PASCAL 

"cmptng_rlease_pnt ; " ) 

($SETQ  DEFEND_RELEASE_POINT_COMPUTED  ’TRUE))]  ]  ] 


(FIND_PARAMETER_RULE_RELATIONS  *DEFENDER_PARAMETERS*  *DEFENDER_RULES* ) 
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Figure  7.3  Spoofer  Knowledge  Base 


S,  D  (Observer) 


Listing  7.3  Spoofer  Knowledge  Base 


spoofer  kb  for  SAM  attack  demo 

shared  parameters  (with  defender/observer)  INBOUND_ENMEY 


(SETQ  *  S YSTEM_ID_CH ARACTER  *  "S4") 
(SETQ  *EXPERT_ID*  "spoofer") 

spoofer  parameters 


[  INTERN_SYMBOL_GROUP  *SPOOFER_PARAMETERS* 

[ SPOOFER_SEARCH_COMPLETED 

(EXPECT  'BOOLEAN)] 

[ SPOOFER_ASSISTANCE_TO_ATTACK 

(EXPECT  ' (NOT_NEEDED,  COMPLETED)] 

[ ECM_DEPLOYMENT_COMPLETED 

(EXPECT  ’BOOLEAN)] 

] 

spoofer  rules 

[ INTERN_SYMBOL_GkOUP  * SPOOFER_RULES * 

[RULE_S01 

[PREMISE  ' ($DETERMINE_VALUE_OF  SPOOFER_ASSISTANCE_TO_ATTACK) ] 
[ACTION  ' ($SETQ  SPOOFER_SEARCH_COMPLETED  ’TRUE)] 

] 


[RULE_S02 

[PREMISE  '  ( $NOT  ($EQ  INBOUND_ENEMY  ’NONE))] 

[ACTION  ' ( 

($ PASCAL 

" f ndng_apprp_ECM ; 
deploying_ECM ; " ) 

($SETQ  ECM_DEPLOYMENT_COMPLETED  ’TRUE) 

($SETQ  SPOOFER__ASSISTANCE_TO_ATTACK  'COMPLETED))]  ] 


[RULE_S03 

[PREMISE  ' ($EQ  I NBOUND_ENEMY  'NONE)] 

[ACTION  ’ ($SETQ  SPOOFER_ASSISTANCE_TO_ATTACK  ' NOT_NEEDED ) ]  ] 

] 


( F I ND_PARAMETER_RULE_RELAT IONS  * S P OOFER_P ARAMETERS *  *SPOOFER_RULES* ) 


Figure  7.4  Navigator  Knowledge  Base 
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Listing  7.4  Navigator  Knowledge  Base 


navigator  kb  for  SAM  attack  demo 

shared  parameter  (with  defender/observer)  is  I NBOUND_ENEMY 


(SETQ  *SYSTEM_ID_CHARACTER*  "N4") 
(SETQ  *EXPERT_ID*  "navigator") 

navigator  parameters 


[  INTERN_SYMBOL_GROUP  * NAVIGATOR_PARAMETERS * 

[ NAVIGATOR_SEARCH_COMPLETED 

(EXPECT  ’BOOLEAN)] 

[ NAVIGATOR_ASSISTANCE_TO_ATTACK 

(EXPECT  ' (NOT_NEEDED,  COMPLETED)] 

[ CLOSEST_BASE_FOUND 

(EXPECT  ’BOOLEAN)] 

[ FRIENDLY_AC_FOUND 

(EXPECT  ’BOOLEAN)] 


navigator  rules 

[  INTERN_SYMBOL_GROUP  * NAVIGATOR_RULES * 

[RULE_N01 

[PREMISE  ' ( $DETERMINE_VALUE_OF  NAVIGATOR_ASSISTANCE_TO_ATTACK ) ] 
[ACTION  ' ($SETQ  NAVIGATOR_SEARCH_COMPLETED  ’TRUE)] 


[RULE_N02 

[PREMISE  '  ($NOT  ($EQ  INBOUND__ENEMY  ’NONE))] 

[ACTION  ' ( 

($ PASCAL 

" fndng_clsest_base ; 
f ndng_frndly_AC ; " ) 

($SETQ  CLOSEST_BASE_FOUND  ’TRUE) 

($SETQ  FRIENDLY_AC_FOUND  ’TRUE) 

($SETQ  NAYIGATOR_ASSISTANCE_TO_ATTACK  ’COMPLETED))]  ] 


[RULE_N03 

[PREMISE  ' ($EQ  INBOUND_ENEMY  ’NONE)] 

[ACTION  '(  ($SETQ  NAVIGATOR_ASSISTANCE_TO_ATTACK  ' NOT_NEEDED) 
( $SETQ  CLOSEST_BASE_FOUND  ’FALSE) 

( $SETQ  FR I ENDLY_AC_FOUND  ’FALSE)  )]  ] } 
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Figure  7.5  Executive  Knowledge  Base 
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Listing  7.5  Executive  Knowledge  Base 

executive  kb  for  SAM  attack  demo 

assumes  executive  gives  clearance  for  defensive  missile  launch 
assumes  successful  defense 

shared  parameters  (with  defender)  are  DEFEND_SUCCESS 

LAUNCH_CLEARANCE 

(with  observer)  INBOUND_ENEMY 


(SETQ  *SYSTEM_ID_CHARACTER*  "X4") 
(SETQ  *EXPERT_ID*  "executive") 

executive  parameters 


[ 1NTERN_SYMB0L_GR0UP  *  EXECUT IVE_P ARAMETERS * 

[ EXECUTIVE_SEARCH_COMPLETED 

(EXPECT  ’BOOLEAN)] 

[ EXECUT I VE_ASS I S  TANC E_TO_ATT AC K 
(EXPECT  ’BOOLEAN)] 

[ S I TUAT I ON_ANALY ZED 

(EXPECT  ’BOOLEAN)] 

[ADDITIONAL_TASKS_ORDERED 

(EXPECT  ’BOOLEAN)] 

[ SUCCESS_DETERMI NED 

(EXPECT  ’BOOLEAN)] 

[ LAUNCH_CLEARANCE 

(EXPECT  ’ (GO  NOGO) )] 


executive  rules 

[ INTERN_SYMBOL_GROUP  * EXECUT I VE_RULES* 

[RULE_X01 

[PREMISE  ’ ( $0R  ( $EQ  I NBOUND_ENEMY  ’NONE) 

( $AND  ( $EQ  EXECUTIVE_ASSISTANCE_TO_ATTACK  ’TRUE) 

( $DETERMINE_VALUE_OF  SUCCESS_DETERMINED) ) ) ] 
[ACTION  ’ ($SETQ  EXECUTIVE_SFARCH_COMPLETED  ’TRUE)] 


[RULE_X02 

[PREMISE  ’ ( $NOT  ($EQ  INBOUND_ENEMY  ’NONE))] 

[ACTION  ’ ( 

($ PASCAL 

" anlyzing_situtn ; 
chckng_mssion_plan ; " ) 

($ PASCAL 

"wts ( ’ ’ adtnal_tsks_ordrd ’ ’ , 1 , new_line ( executive ) , executive ) ; " ) 
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($SETQ  S I TU AT I ON_AN ALY  ZED  'TRUE) 

($SETQ  ADDITIONAL_TASKS_ORDERED  'TRUE) 

($SETQ  EXECUTIVE_ASSISTANCE_TO_ATTACK  'TRUE)  )]  ] 


[RULE_X03 

[PREMISE  1 ( $ UNKNOWN  DEFEND_SUCCESS ) ] 

[ACTION  ' ( $SETQ  SUCCESS_DETERMINED  'FALSE)]  ] 


[RULE_X04 

[PREMISE  ’ ( $EQ  DEFEND_SUCCESS  ’TRUE)] 

[ACTION  '(  ( $ PASCAL 
"gtng__dfns_results  ; 

wts( ’ 'successful  defense1 ' , 1 , new_line( executive) , executive) ; 
wts( ' 'good  work! ' ' , l,new_line( executive) , executive) ; 
delay (1000 ) ; 

initialize_buffers( executive) ; 
of  f_screen ( executive ) ; " ) 

($SETQ  SUCCESS_DETERMINED  ’TRUE)  )]] 

[RULE_X05 

[PREMISE  ' ( $UNKNOWN  LAUNCH_CLEARANCE ) ] 

[ACTION  ' ( 

($ PASCAL 

" frmng_lnch_dcisin ; 

wts( ' 'clrnc_for_lnch_GO! ' ' , l,new_line( executive) , 
executive) / " ) 

( $SETQ  LAUNCH_CLEARANCE  ’GO))]  ] 


(FIND_PARAMETER_RULE_RELATIONS  * EXECUT IVE_P ARAMETERS *  *EXECUTIVE_RULES* ) 
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Listing  7.fc  Copilot  Knowledge  Base 

copilot  kb  for  SAM  attack  demo 

shared  parameter  (with  defender/observer)  is  I NBOUND_ENEMY 

(SETQ  *SYSTEM_ID_CHARACTER*  "C4") 

(SETQ  *EXPERT_ID*  "copilot") 

copilot  parameters 


[  INTERN_SYMBOL_GROUP  *COP ILOT_PARAMETERS * 

[ COPILOT_SEARCH_COMPLETED 

(EXPECT  ’BOOLEAN)] 

[ COP ILOT_ASS I STANCE_TO_ATTACK 
(EXPECT  ’BOOLEAN)] 

[ EVAS IVE_MANEUVER_FOUND 

(EXPECT  ’BOOLEAN)] 


copilot  rules 

[  INTERN_SYMBOL_GROUP  *COPILOT_RULES * 

[RULE_C01 

[PREMISE  ’ ($0R  ($EQ  I NBOUND_ENEMY  ’NONE) 

( $EQ  COP ILOT_ASS I STAN CE__TO_ATTACK  ’TRUE)  )] 

[ACTION  ’ ($SETQ  COPILOT_SEARCH  COMPLETED  ’TRUE)] 

] 


[RULE_C02 

[PREMISE  ’ ( $NOT  ($EQ  I NBOUND_ENEMY  ’NONE))] 
[ACTION  ’ ( 

( $ PASCAL 

" f ndng_evsve_mnvrs ; " ) 

($SETQ  EVAS IVE_MANEUVER_FOUND  ’TRUE) 

($SETQ  COPILOT_ASSISTANCE_TO_ATTACK  ’TRUE)  )] 

]  ] 


(FINDJPARAMETER_RULE_RELATIONS  *COPILOT_PARAMETERS*  *COPILOT_RULES* ) 
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Figure  7.7  Observer  Knowledge  Base 


Listing  7.7  Observer  Knowledge  Base 


observer  kb  for  SAM  attack  demo 

shared  parameters  (with  eight  remaining  knowledge  bases)  are 

INBOUND_ENEMY 
INBOUND  DIRECTION 


(SETQ  *SYSTEM_ID_CHARACTER*  "04”) 
(SETQ  *EXPERT_ID*  "observer") 

observer  parameters 


[  INTERN_SYMBOL_GROUP  * OBSERVER  JPARAMETERS * 


[  OBSERVER_SEARCH_COMPLETED 

(EXPECT  'BOOLEAN)] 

[  OBSERVER_AS  S ISTANCE_TO_ATTACK 
( EXPECT  ’ BOOLEAN ) ] 


[INBOUND_ENEMY 

(EXPECT  ’(NONE,  SAMS,  AAMS,  GUNFIRE)] 

[  INBOUNDJDIRECTION 

(EXPECT  'INTEGER)] 


% 

.V 

wt 

Vi 


] 

"  • 

observer  rules  !■' 

'ji 

[INTERN  SYMBOL  GROUP  * OBSERVER  RULES*  V 


[RULE_001  w 

V 

[PREMISE  ' ( $AND  ( $DETERMINE_VALUE_OF  INBOUND_ENEMY )  V 

( $  DETERMI NE_VALUE_OF  OBSERVER_ASS I STANCE_TO_ATTACK ) ) ]  v 

[ACTION  ' ($SETQ  OBSERVER_SEARCH_COMPLETED  'TRUE)]  V 

]  'A 


[RULE_O02 

[PREMISE  ' ($UNKNOWN  I NBOUND_ENEMY ) ] 

[ACTION  ' ( 

( $SETQ  INBOUND_ENEMY  ’NONE) 

($SETQ  INBOUND_DIRECTION  '0) 

($ PAS CAL 

"wts( ' 'all  clear' ' , l,new_line( observer) , observer) ; 
get_key,-"))]  ] 
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[  RULE_00  3 

[PREMISE  1 ( $ KNOWN  INBOUND_ENEMY ) ] 
[ACTION  ' ( 

($ PASCAL  ”  get_key;  ") 

($SETQ  INBOUND_ENEMY  INBOUND_ENEMY ) 
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($SETQ  INBOUND_DIRECTION  INBOUND_DIRECTION) ) ]  ] 


[RULE_O04 

[PREMISE  ' ( $NOT  ($EQ  INBOUND_ENEMY  'NONE))] 
[ACTION  ' ( 

( $ PASCAL  " fndng_SAM_lnchpt ; " ) 

($SETQ  OBSERVER_ASSISTANCE_TO_ATTACK  'TRUE))]  ] 


[RULE_O05 

[PREMISE  ' ($EQ  INBOUND_ENEMY  ’NONE)] 

[ACTION  '  ($SETQ  OBSERVER_ASSISTANCE_TO__ATTACK  'FALSE)]  ] 


( F I ND_PARAMETER_RULE_RELAT IONS  *OBSERVER_PARAMETERS*  *OBSERVER_RULES* ) 
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Listing  7.8  Engineer  Knowledge  Base 


~  engineer  kb  for  SAM  attack  demo 

~  shared  parameter  (with  defender/observer)  is  I NBOUND_ENEMY 


(SETQ  *SYSTEM_ID_CHARACTER*  "E4") 
(SETQ  *EXPERT_ID*  "engineer") 

engineer  parameters 


t INTERN_SYMBOL_GROUP  *ENGINEER_PARAMETERS  * 

[ ENG INEER_SEARCH_COMPLETED 

(EXPECT  'BOOLEAN)] 

[ENGINEER_ASSISTANCE_TO_ATTACK 
(EXPECT  'BOOLEAN)] 


engineer  rules 

[ INTERN_SYMBOL_GROUP  * ENGINEER_RULES * 

[RULE_E01 

[PREMISE  ' ( $OR  ($EQ  I NBOUND_ENEMY  ’NONE) 

( $EQ  ENG I NEER_ASS I STANCE_TO_ATTACK  ’TRUE)  )] 

[ACTION  ' ($SETQ  ENGINEER_SEARCH_COMPLETED  ’TRUE)] 


[RULE_E02 

[PREMISE  ' ($NOT  ($EQ  INBOUND_ENEMY  'NONE))] 
[ACTION  ' ( 

( $ PASCAL 

"mntrng_systems ; 
cmpting_AC_capablts ; " ) 

($SETQ  ENGINEER_ASSISTANCE_TO_ATTACK  ’TRUE)  )] 


( FIND_PARAMETER_RULE_RELATIONS  *ENGINEER_PARAMETERS*  *  ENG I NEER_RULES  * ) 


f# 

* 

«£; 


NONE 


Listing  7.9  Communicator  Knowledge  Base 

communicator  kb  for  SAM  attack  demo 

shared  parameter  (with  defender/observer)  is  INBOUND_ENEMY 

(SETQ  *SYSTEM_ID_CHARACTER*  "M4") 

(SETQ  *EXPERT__ID*  "communicator") 

communicator  parameters 

[  INTERN_SYMBOL_GROUP  *  COMMUN I CATOR_P ARAMETERS * 

[ COMMUNICATOR_SEARCH_COMPLETED 
(EXPECT  'BOOLEAN)] 


[  COMMUN  I  CATOR__AS  S I  STANCE_TO_ATTACK 
(EXPECT  'BOOLEAN)] 

[MESSAGES_OUT_COMPLETED 

(EXPECT  ’BOOLEAN)] 


[MESSAGES_IN_ASSEMBLED 

(EXPECT  ’BOOLEAN)] 

(RULE_TESTED 

(EXPECT  'BOOLEAN) 

( INITIAL_VALUE  'TRUE)] 


communicator  rules 

[ INTERN_SYMBOL_GROUP  *COMMUNICATOR_RULES* 

[RULE_M01 

[PREMISE  ' ( $0R  ( $EQ  INBOUND_ENEMY  'NONE) 

($EQ  COMMUN I C ATOR_AS S I STANCE_TO_ATTACK  'TRUE)  )] 

[ACTION  ' ($SETQ  COMMUN I CATOR_SEARCH_COMPLETED  'TRUE)] 


[  RULE_M0  2 

[PREMISE  ' ($AND  ($EQ  MESSAGES_OUT_COMPLETED  ’TRUE) 

($EQ  MESSAGES_IN_ASSEMBLED  ’TRUE))  ] 

[ACTION  ' ($SETQ  COMMUNICATOR_ASSISTANCE_TO_ATTACK  ’TRUE)  ] 


[RULE_M03 

[PREMISE  ' <$EQ  RULE_TES TED  ’TRUE)] 

[ACTION  ' ( 

($ PASCAL 
"roessages_out ; 

wts( ' 'AC#3  under  SAM  atk' l,new_line( communicator) communicator) ; 


8.  Consolidation  Of  AUTOCREW  Component  Knowledge  Bases  Into  One  Process 


AUTOCREW  knowledge  bases  are  developed  and  implemented  individually. 
When  a  simulation  process  that  includes  all  knowledge  bases  is  developed,  the  rules  and 
parameters  of  the  individual  knowledge  bases  must  first  be  consolidated  into  single 
process  lists.  The  resulting  parameter-rule  relationships  represents  a  single  process 
knowledge  base  containing  all  nine  systems. 

The  following  Princeton  Rule-Based  Controller  (PRBC)  [2]  system  software 
commands  perform  the  tasks  described.  First,  each  AUTOCREW  knowledge  base  is 
loaded  into  the  LISP  environment  with  the  FLOAD  command.  The  component 
knowledge-base  parameters  and  rules  are  consolidated  into  larger  lists  with  the 
CONSOLIDATE  command.  Finally,  the  process  knowledge  base  is  formulated  with 
the  FIND  PARAMETER  RULE_RELATIONS  command. 


>’sV.V 


THAI 


this  file  consolidates  all  '4  lisp  files  to  simulate  1  process 
this  simulation  shows  AUTOCREW  response  to  an  inbound  SAM 


(SETQ  *SYSTEM_ID_CHARACTER*  "4") 

attacker 
(FLOAD  " KB_A4 " ) 

spoofer 

(FLOAD  "KB_S4 " ) 

navigator 
(FLOAD  "KB_N4 " ) 

copilot 

(FLOAD  " KB_C4 " ) 

observer 
(FLOAD  " KB_04 " ) 

executive 
(FLOAD  " KB_X4 " ) 

engineer 
(FLOAD  "KB_E4") 

communicator 
(FLOAD  " KB_M4 " ) 

defender 
(FLOAD  "KB_D4 " ) 

( F IND_P  ARAMETER_RULE_RELAT IONS  (CONSOLIDATE  * ATTACKER_P ARAMETERS * 

* S POOFER_PARAMETERS * 

*  NAVIGATOR_P ARAMETERS  * 

*  COP ILOT_P ARAMETERS  * 

*  OBSERVER_P ARAMETERS * 

*  EXECUTIVE_PARAMETERS  * 

*  ENG I NEER_P ARAMETERS  * 

*  COMMUN I CATOR_P ARAMETERS * 
*DEFENDER_P ARAMETERS* ) 

(CONSOLIDATE  * ATTACKER_RULES * 

* SPOOFER_RULES* 

*  NAVIG ATOR_RULES * 

*  COP I LOT_RULES  * 

*  OBSERVER_RULES* 

* EXECUT IVE_RULES * 

*  ENG I NEER_RULES * 

* COMMUNICATOR_RULES * 

*  DEFENDER_RULES  * ) 


9.  Process  Knowledge-Base  Map 


Graphical  knowledge-base  representation  provides  the  best  overview  of 
knowledge-base  logic  and  functions  in  comparison  with  code  inspection.  The  PRBC 
development  system  facilitates  logic  tracing  by  providing  a  mapping  procedure  that 
shows  how  the  parameters  are  set  and  used  by  rules.  For  example,  the  representation 

5 - ECM_DEPLOYMENT_COMPLETED -  5 

(15)  RULE_S02  ->  (*  4) 


reads, 

"Rule  S02  uses  parameter  #15  to  set  parameter 
ECM_DEPLOYMENT_COMPLETED  and  parameter  #4" 

The  representation 

4  . SPOOFER_ASSISTANCE_TO_ATTACK  . . 4 

(*)  RULE_SO!  ->  (3) 


reads, 

the  parameter  SPOOFER_ASSISTANCE_TO_ATTACK  is  used  uy 
RULE  SOI  to  set  parameter  #3" 


The  drawback  of  the  PRBC  representation  is  that  the  parameter  values  are 
invisible,  so  that  a  direct  reconstruction  of  the  rule  is  not  possible.  In  contrast,  the 
graphical  representation  facilitates  direct  reconstruction  of  the  rules  found  in  the 
knowledge-base  code  (or  vice-versa).  The  advantage  of  the  PRBC  knowledge-base 
map  representation  is  its  provision  of  a  condensed  parameter/rule  interaction  "history". 

The  following  PRBC  output  is  a  parameter/rule  map  of  the  inbound  SAM 
attack  process  knowledge  base. 


Expert  System  4  Knowlecje  Base  Map 


(2) 

RULE_A0 1  -> 

(4) 

RULE_S01  -> 

(15) 

RULE  S02  -> 

(15) 

RULE_S03  -> 

(15) 

RULE_S02  -> 

(7) 

RULE_N01  -> 

(15) 

RULE  N02  -> 

(15) 

RULE_N03  -> 

(15) 

RULE  N02  -> 

(15) 

RULE_N03  -> 

(15) 

RULE  N02  -> 

(15) 

RULE_N03  -> 

(11  15) 

RULE_C0 1  -> 

(15) 

RULE_C02  -> 

(15) 

RULE_C02  -> 

(14  15) 

RULE_O01  -> 

(15) 

RULE  004  -> 

(15) 

RULE_00  5  -> 

ATTACKER_SEARCH_COMPLETED  - 

(  *  ) 


CLOS I NG_ON_TARGET  - 

(*)  RULE_A01  ->  (1) 

S POOFER_S EARCH_COMPLETED 
(*) 


SPOOFER_ASSISTANCE_TO_ATTACK  - 
(*)  RULE_S01  ->  (3) 

(*  5) 

(*) 


ECM_DEPLOYMENT_COMPLETED  - 

(*  4) 

NAVI G ATOR_SEARCH_COMPLETED  - 

(*) 

NAVI G ATOR_AS  S I STANCE_TO_ATTACK 
(*)  RULE_N01  ->  (6) 

(*  8  9) 

(*  8  9) 


CLOSES  TJBASEyOUND 
(*  7  9) 

(*  7  9) 

FRIENDLY_AC_FOUND  - 
(*  7  8) 

(*  1  8) 


COPILOT_SEARCH_COMPLETED  - 

(*) 

COP  I  LOT_AS  S I  STANCE_TO__ATTACK  - 
(*  15)  RULE_C01  ->  (10) 

(*  12) 


EVAS IVE_MANEUVER_FOUND  - 

(*  ID 

OBSERVER_SEARCH_COMPLETED  - 

(*) 

OBSERVER_ASS ISTANCE_TO_ATTACK 
(*  15)  RULE_001  ->  (13) 

(*) 

(*) 


INBOUND_ENEMY  - 

(*)  RULE_S02  ->  (4  5) 
(*)  RULE_S03  ->  (4) 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


(33) 

RULE_D02  -> 

(15) 

RULE  002  -> 

(15) 

RULE_O03  -> 

(15  18  21) 

RULE_X01  -> 

(15) 

RULE_X02  -> 

(15) 

RULE_X02  -> 

(15) 

RULE_X02  -> 

(31) 

RULE  X03  -> 

(31) 

RULE_X04  -> 

(15  24) 

RULE_E01  -> 

(15) 

RULE_E0  2  -> 

(15  26) 

RULE_M01  -> 

(*)  RULE_N02  ->  (7  8  9) 

(*)  RULE_N03  ->  (7  8  9) 

(*  11)  RULE_C01  ->  (10) 

(*)  RULE_C02  ->  (11  12) 

(*  14)  RULE_O01  ->  (13) 

(*)  RULE_O0 2  ->  (*  16) 

(*)  RULE_003  ->  (*  16) 

(*)  RULE_O04  ->  (14) 

(*)  RULE_O05  ->  (14) 

(*  18  21)  RULE_X0 1  ->  (17) 
(*)  RULE_X02  ->  (18  19  20) 
(*  24)  RULE_E0 1  ->  (23) 

(*)  RULE_E02  ->  (24) 

(*  26)  RULE_M01  ->  (25) 

(*  31)  RULE_D01  ->  (30) 

(*  33)  RULE_D0 3  ->  (31  32) 
(*)  RULE_O0 2  ->  (*  16) 

(*)  RULE_003  ->  (*  16) 

(*  31  32) 


INBOUND_DIRECTION  - 

(*)  RULE_D07  ->  (34  39  40) 
(*  15) 

(*  15) 

EXECUTIVE  SEARCH  COMPLETED 


16 


EXECUTIVE_ASSISTANCE_TO_ATTACK 
(*  15  21)  RULE_X01  ->  (17) 


SITUATION  ANALYZED 


ADDITIONAL  TASKS  ORDERED 


SUCCESS_DETERMINED  - 

(*  15  18)  RULE_X01  ->  (17) 


LAUNCH_CLEARANCE  - 

(*)  RULE_X05  ->  (*) 

(*)  RULE_X05  ->  (*) 

ENGINEER  SEARCH  COMPLETED 


ENG I NEER_ASS I STANCE_TO_ATTACK 
(*  15)  RULE_E01  ->  (23) 

(*) 

COMMUNICATOR  SEARCH  COMPLETED 


23 


24 


25 


COMMUNICATOR  ASSISTANCE  TO  ATTACK  -  26 
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(*  15)  RULE_M01  ->  (25) 
(27  28)  RULE_M02  ->  (*) 


27  -  MESSAGES_OUT_COMPLETED 

(*  28)  RULE_MO 2  ->  (26) 
(29)  RULE_M03  ->  (*  28) 

28  -  MESSAGES_IN_ASSEMBLED  - 

(*  27)  RULE_M02  ->  (26) 
(29)  RULE_M03  ->  (*  27) 

29  - RULE  TESTED - 


(*)  RULE_MO 3  ->  (27  28) 
(*)  RULE_D06  ->  (38) 

(*)  RULE_DO 8  ->  (36  41) 
(*)  RULE_D10  ->  (42) 

(*)  RULE_D11  ->  (37) 


30  -  DEFENDER_SEARCH_COMPLETED 

(15  31)  RULE_D01  ->  (*) 

31  -  DEFEND_SUCCESS  - 

(*)  RULE_X03  ->  (21) 

(*)  RULE_X04  ->  (21) 

(*  15)  RULE_D01  ->  (30) 
(33)  RULE_D0 2  ->  (*  15  32) 

(15  33)  RULE_D03  ->  (*  32) 


32  -  JEFEND_COUNTDOWN_RELEASE  - 

(33)  RULEJD02  ->  (*  15  31) 

(15  33)  RULE_D03  ->  (*  31) 

33  -  ATTACK_OR_ABORT  - 

(*)  RULE__D0 2  ->  (15  31  32) 


(*  15)  RULE_D0 3  ->  (31  32) 
(34  35  37  38)  RULE_D04  ->  {*) 

(38)  RULE_D05  ->  (*) 


34  -  TRAJECTORY_COMPUTED  - 

(*  35  37  38)  RULE  D04  ->  (33) 
(16)  RULE_D0 7  ->  (*  39  40) 

35  -  DEFEND_WEAPON_SELECTED  - 

(*  34  37  38)  RULE_D04  ->  (33) 
(41  42)  RULE_D09  ->  (*) 

36  -  WEAPON_RECOMMENDED  - 

(29)  RULE_D0 8  ->  (*  41) 

37  -  DEFEND_RELEASE_POINT_COMPUTED 

(*  34  35  38)  RULE_D04  ->  (33) 
(29)  RULE_D11  ->  <*) 

38  -  P I LOT_CONF I RMED_ENEMY  - 

(*  34  35  37)  RULE_D04  ->  (33) 
(*)  RULE_D0 5  ->  (33) 

(29)  RULE_D06  ->  (*) 


27 


28 


29 


30 


31 


32 


33 


34 


35 


36 


37 


38 


-  DEFEND_FIRE_CONTROL_STATUS 

(16)  RULE_D07  ->  (*  34  40) 

-  DEFEND_TRACK_SCAN  - 

(16)  RULE  DO 7  ->  (*  34  39) 


10.  PASCAL  Implementation  of  Inbound  SAM  Attack  Simulation 


When  the  process  knowledge-base  has  been  formulated  in  the  LISP 
environment,  it  can  be  translated  into  the  PASCAL  environment  using  the  PRBC 
development  system  software.  A  PASCAL  implementation  of  the  depth-first  search 
inference  engine  then  operates  on  the  translated  knowledge  base.  The  rule-based  logic 
flow  proceeds  in  the  same  manner  as  in  the  LISP  environment  albeit  faster  and  without 
LISP-related  process  interruptions  such  as  garbage  collection.  Additionally,  PASCAL 
code  or  procedure  calls  embedded  in  the  knowledge  base  may  be  executed.  Hence, 
numerical  code  is  developed  in  the  naturally  procedural  language  PASCAL,  and  the 
knowledge  base  is  developed  in  the  naturally  symbolic  language  LISP.  The  ease  with 
which  PASCAL  code  can  be  embedded  in  the  knowledge  base  structure  makes  the 
PRBC  a  highly  suitable  tool  for  task  and  algorithm  scheduling. 

The  following  PASCAL  program  listing  shows  the  high-level  implementation 
of  the  inbound  SAM  attack  AUTOCREW  simulation.  The  included  files  "KB_4.TYP" 
and  "KB_4.VAR"  contain  the  parameter/rule  declaration  and  variable  statements.  The 
file  "INFER.BB"  contains  utility  functions  and  the  PASCAL  implementation  of  the 
inference  engine.  The  next  four  included  files  contain  the  AUTOCREW  simulation 
testbed  code  to  drive  the  graphics,  user-interface  and  programmed  keys  for  simulation 
control.  The  included  file  "KB_4.INC"  contains  PASCAL  dummy  procedure  shells 
formed  by  the  PRBC  PASCAL  Tag  Generator  utility  [1].  These  program  shells  send 
messages  to  the  AUTOCREW  graphics  interface  describing  the  task  to  be  performed  by 
their  implied  procedure  name.  The  task  may  not  yet  be  coded,  but  the  designer  can  still 
define  the  knowledge-base  structure.  Hence,  rapid  prototyping  of  cooperating 
rule-based  systems  is  facilitated,  and  the  code  can  be  developed  in  depth  at  a  more 
convenient  time,  when  the  designer  is  satisfied  with  a  particular  ensemble  prototype. 
The  remaining  included  files  "KB_4.PRE"  and  "KB_4.ACT"  contain  PASCAL 
translations  of  the  premise  (if)  and  action  (then)  statements  respectively  which  are  found 
in  the  process  knowledge  base. 

Before  search  may  commence,  the  parameters  must  be  initialized  (ikb 
command).  Without  initialization,  the  inference  engine  cannot  establish  the  state  of  the 
knowledge  base  and  cannot  proceed  with  the  search.  The  top-level  parameters  of  the 
OBSERVER  and  DEFENDER  are  searched.  Upon  completing  a  pass  through  each 
knowledge  base,  all  parameters  are  reinitialized  and  the  search  commences  again  (repeat 
ikb  ...  until).  Goal-directed  search  on  the  top-level  parameters  of  the  remaining 
AUTOCREW  components  is  invoked  from  within  the  DEFENDER  knowledge  base  in 


w  ui  w  uv 


program  expert_4 ; 
label  start_here ; 


{$1  \PRBC\BRENDA\KB_4 . TYP  } 

{$1  \PRBC\BRENDA\KB_4 . VAR  } 

[$I  \PRBC\BRENDA\INFER.BB  } 

{$1  \PRBC\BRENDA\AUTOCREW . VAR 
{ $ I  \PRBC\BRENDA\GRAPHICS . BB } 
{$1  \PRBC\BRENDA\EXSPECIF . BB  } 
{$1  \PRBC\BRENDA\KEYS_D. BB  } 
($1  \PRBC\BRENDA\KB_4 . INC  } 

{$1  \PRBC\BRENDA\KB_4 . PRE  } 

{$1  \PRBC\BRENDA\KB_4 . ACT  } 


{##### 

begin 


MAIN  PROGRAM  ############################################} 


verbose  :«  false; 

if  verbose  «  false  then  start_up_di splay; 
if  verbose  -  true  then  window(l,l,80,25) ; 
read_knowledge_base ; 


start  here: 


repeat 

ikb; 

dvo ( observer_search_completed ) ; 
dvo ( def ender_search_completed ) ; 
until  keystroke  -  helpp; 
get_help ; 
goto  start_here; 


end .  { exper t_4 } 


4-2 


-!v 


m 


$s 


M 


i 


•V' 


9 


•y, 

& 


*  V* 

i 


Ss 


?! 


•s 


?! 


OvV 


■Vi 
s, 


I 


& 


m 


'-2A  sJ 


*.>J 

‘•..‘•I 


p  j'L  a?  e£> 

3)~r/c 

7-  er 


<r.<r.  »v<v  vr^  >r  '  ',rv  <’  •,*7.'  i"  •  >,  «,.%  » vs'-  ;  *,  • ,  v--1, •  wry  tv 

V  ; 


